Refactor context usage and keeper calls #382
Conversation
📝 WalkthroughWalkthroughThis pull request refactors various modules to replace indirect method calls through embedded fields (typically the Changes
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (22)
app/app.go(2 hunks)app/export.go(2 hunks)crypto/ledger/usbwallet/wallet.go(1 hunks)x/bank/keeper/custom_msg_server.go(1 hunks)x/distribution/keeper/custom_grpc_query.go(3 hunks)x/distribution/keeper/grpc_query.go(3 hunks)x/dynamic-fee/keeper/ante.go(2 hunks)x/gov/abci.go(1 hunks)x/gov/keeper/custom_grpc_query.go(4 hunks)x/gov/keeper/msg_server.go(5 hunks)x/ibc/perm/keeper/grpc_query.go(1 hunks)x/ibc/perm/keeper/msg_server.go(4 hunks)x/move/client/cli/utils.go(1 hunks)x/move/keeper/api.go(3 hunks)x/move/keeper/balancer.go(2 hunks)x/move/keeper/keeper.go(5 hunks)x/move/keeper/msg_server.go(10 hunks)x/move/keeper/querier.go(2 hunks)x/move/keeper/vesting.go(1 hunks)x/mstaking/keeper/compatibility_keeper.go(1 hunks)x/mstaking/keeper/grpc_query.go(8 hunks)x/mstaking/keeper/msg_server.go(1 hunks)
🧰 Additional context used
🧬 Code Definitions (2)
x/move/keeper/keeper.go (2)
x/move/types/keys.go (5)
ModuleSeparator(67-67)ChecksumSeparator(68-68)ResourceSeparator(69-69)TableInfoSeparator(71-71)TableEntrySeparator(70-70)api/initia/move/v1/types.pulsar.go (3)
TableEntry(6333-6343)TableEntry(6358-6358)TableEntry(6361-6363)
crypto/ledger/usbwallet/wallet.go (1)
crypto/ledger/accounts/account.go (1)
MimetypeTypedData(41-41)
🔇 Additional comments (63)
x/ibc/perm/keeper/grpc_query.go (1)
38-38: Improved method access patternThis change correctly simplifies the method call by using the promoted
GetChannelStatemethod directly from theQueryServerImplstruct, rather than accessing it through the embeddedKeeperfield. This makes the code more concise and improves readability.x/move/keeper/vesting.go (1)
93-93: Streamlined keeper accessThe change correctly accesses
MoveBankKeeperdirectly from theVestingKeeperstruct rather than through the embeddedKeeperfield. This is in line with the PR's objective to enhance the consistency of keeper method calls.x/bank/keeper/custom_msg_server.go (1)
36-36: Direct method call improvementThis change correctly calls
SetDenomMetaDatadirectly on thecustomMsgServerinstance instead of through the embeddedKeeperfield. This follows the same pattern as other refactored files, creating more consistent and cleaner code.crypto/ledger/usbwallet/wallet.go (1)
591-591: Improved conditional logic readabilityThe change enhances readability by replacing a negated complex condition with a more straightforward expression using explicit OR conditions. This makes the code easier to understand while maintaining the same logical behavior.
x/move/keeper/keeper.go (1)
567-646: Improved code organization with switch statementThe refactoring from if-else chains to a switch statement significantly improves code readability and maintainability. This change makes the control flow more explicit and easier to follow by organizing related logic into distinct cases based on the separator value.
x/dynamic-fee/keeper/ante.go (2)
21-21: Direct field access improves code clarityThe change removes indirect access through the
Keeperfield, making the code more direct and less verbose by accessingbaseDenomKeeperdirectly.
31-31: Direct field access improves code claritySimilar to the previous change, this refactoring removes an unnecessary indirection through the
Keeperfield, making the code more direct and easier to understand.x/move/client/cli/utils.go (1)
138-147: Better control flow with switch statement for boolean parsingThe refactoring from if-else chains to a switch statement improves code organization when handling multiple conditional cases. The addition of a default case for unsupported boolean values also makes the error handling more explicit.
app/app.go (2)
476-476: Direct method access eliminates redundant qualificationRemoved the unnecessary
BaseAppqualification when callingGRPCQueryRouter(), since this method is already accessible through theInitiaAppinstance. This simplifies the code and adheres to Go's inheritance pattern where embedded struct methods can be called directly.
491-491: Direct method access eliminates redundant qualificationSimilar to the previous change, this removes the redundant
BaseAppqualification when accessing theGRPCQueryRouter()method, improving code conciseness while maintaining the same functionality.x/mstaking/keeper/compatibility_keeper.go (2)
25-25: Method access simplified using embedded field promotionThe change removes the explicit reference to the embedded
Keeperfield, instead calling the method directly on theCompatibilityKeeperinstance, which is cleaner and follows Go's idiomatic use of embedded types.
33-33: Method access simplified using embedded field promotionSimilar to the previous change, this removes the redundant reference to the embedded
Keeperfield when callingGetValidatorByConsAddr, making the code more concise and idiomatic.x/ibc/perm/keeper/msg_server.go (6)
28-28: Field access simplified using embedded field promotionThe change removes the unnecessary reference to the embedded
Keeperfield when accessingac, making the code more concise while maintaining the same functionality.
32-32: Method access simplified using embedded field promotionThe call to
GetChannelStatehas been updated to use the promoted method from the embeddedKeeper, reducing verbosity while preserving behavior.
43-43: Method access simplified using embedded field promotionThe call to
SetChannelStatenow directly uses the method promoted from the embeddedKeepertype, improving code clarity.
70-70: Field access simplified using embedded field promotionSimilar to the earlier change, this simplifies access to the
acfield by leveraging method promotion from the embeddedKeeper.
74-74: Method access simplified using embedded field promotionThis change follows the same pattern of simplifying method calls by leveraging Go's promotion of methods from embedded types.
85-85: Method access simplified using embedded field promotionThe call to
SetChannelStatehas been updated to be more concise by removing the explicit reference to the embeddedKeeper.app/export.go (2)
52-52: Method access simplified using embedded field promotionThe change removes the explicit reference to
BaseAppwhen callingGetConsensusParams, instead relying on method promotion from the embedded type. This makes the code more concise while preserving the same functionality.
61-61: Boolean assignment simplifiedThe conditional logic for setting
applyAllowedAddrshas been refactored into a more concise form, directly assigning the boolean result of the conditionlen(jailAllowedAddrs) > 0. This is a common Go idiom that improves readability.x/gov/abci.go (1)
237-237: Conditional logic simplified with equivalent expressionThe condition has been refactored from
!(proposal.Expedited && !passed)to the logically equivalent!proposal.Expedited || passed. This makes the code more readable while maintaining the same behavior, using De Morgan's laws of boolean algebra.x/move/keeper/querier.go (2)
51-52: Code simplification: direct VMStore access looks good.The change to access
q.VMStoredirectly instead ofq.Keeper.VMStoreis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.
438-438: Code simplification: direct MoveBankKeeper access looks good.The change to access
q.MoveBankKeeper()directly instead ofq.Keeper.MoveBankKeeper()is a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.x/gov/keeper/msg_server.go (6)
105-105: Code simplification: direct AddDeposit method access looks good.The change to call
k.AddDepositdirectly instead ofk.Keeper.AddDepositis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.
165-165: Code simplification: direct legacyRouter access looks good.The change to access
k.legacyRouter.HasRoutedirectly instead ofk.Keeper.legacyRouter.HasRouteis a clean improvement that reduces verbosity while maintaining the same functionality.
169-169: Code simplification: direct legacyRouter access looks good.The change to access
k.legacyRouter.GetRoutedirectly instead ofk.Keeper.legacyRouter.GetRouteis a clean improvement that reduces verbosity while maintaining the same functionality.
189-189: Code simplification: direct AddVote method access looks good.The change to call
k.AddVotedirectly instead ofk.Keeper.AddVoteis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.
234-234: Code simplification: direct AddVote method access looks good.The change to call
k.AddVotedirectly instead ofk.Keeper.AddVoteis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.
254-254: Code simplification: direct AddDeposit method access looks good.The change to call
k.AddDepositdirectly instead ofk.Keeper.AddDepositis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.x/mstaking/keeper/msg_server.go (1)
527-527: Code simplification: direct authKeeper access looks good.The change to access
ms.authKeeper.AddressCodec()directly instead ofms.Keeper.authKeeper.AddressCodec()is a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.x/gov/keeper/custom_grpc_query.go (4)
89-89: Code simplification: direct Votes collection access looks good.The change to access
q.Votes.Hasdirectly instead ofq.Keeper.Votes.Hasis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.
100-100: Code simplification: direct Deposits collection access looks good.The change to access
q.Deposits.Hasdirectly instead ofq.Keeper.Deposits.Hasis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.
142-147: Switch statement refactoring looks good.The refactoring of the switch statement to combine related cases (StatusPassed and StatusRejected) using a comma-separated format improves code readability while maintaining the same functionality.
156-156: Code simplification: direct Tally method access looks good.The change to call
q.Tallydirectly instead ofq.Keeper.Tallyis a clean improvement that reduces verbosity while maintaining the same functionality through the embedded Keeper struct.x/move/keeper/api.go (3)
65-65: Direct method call refactoring improves code clarity.Changed from indirect method call through embedded
Keeperfield to a direct call on theGoApistruct, which already inherits all methods from the embeddedKeeper.
81-81: Direct method call refactoring improves code clarity.Consistent with the pattern of calling
MoveBankKeeper()directly on theGoApistruct instead of going through the embeddedKeeperfield.
137-137: Direct method call refactoring improves code clarity.Refactored to call
HandleVMQuerydirectly on theGoApistruct, leveraging the method inheritance from the embeddedKeeperfield.x/distribution/keeper/custom_grpc_query.go (3)
54-54: Direct method call refactoring improves code clarity.Changed from indirect method call through embedded
Keeperfield to a direct call on theCustomQueryServerstruct, which already inherits all methods from the embeddedKeeper.
77-77: Direct method call refactoring improves code clarity.Consistent with the pattern of calling
GetValidatorAccumulatedCommissiondirectly on theCustomQueryServerstruct instead of going through the embeddedKeeperfield.
103-103: Direct field access refactoring improves code clarity.Changed from accessing the
ValidatorSlashEventsfield through the embeddedKeeperto accessing it directly from theCustomQueryServerstruct.x/distribution/keeper/grpc_query.go (3)
113-113: Direct method call refactoring improves code clarity.Changed from indirect method call through embedded
Keeperfield to a direct call on theQueryServerstruct, which already inherits all methods from the embeddedKeeper.
137-137: Direct method call refactoring improves code clarity.Consistent with the pattern of calling
GetValidatorAccumulatedCommissiondirectly on theQueryServerstruct instead of going through the embeddedKeeperfield.
165-165: Direct field access refactoring improves code clarity.Changed from accessing the
ValidatorSlashEventsfield through the embeddedKeeperto accessing it directly from theQueryServerstruct.x/move/keeper/balancer.go (2)
108-118: Refactored if-else chain to switch statement for better readability.The switch statement provides a cleaner, more structured approach to handle multiple cases compared to the previous if-else chain, while maintaining identical functionality.
315-320: Refactored if-else chain to switch statement for better readability.Similar to the previous refactoring, this change improves code clarity by using a switch statement for case handling without changing the underlying logic.
x/move/keeper/msg_server.go (10)
46-46: Direct method call improves code clarity.This change replaces the indirect method call (
ms.Keeper.PublishModuleBundle) with a direct call to the embedded method. This pattern is applied consistently throughout the file and aligns with Go's struct embedding best practices.
83-83: Direct method call improves code clarity.Replacing the indirect method call via Keeper with a direct call improves readability while maintaining the same functionality.
123-123: Direct method call improves code clarity.Using the embedded method directly without going through the Keeper field simplifies the code path.
164-164: Direct method call improves code clarity.Consistent with the pattern applied throughout the file - accessing the embedded method directly.
197-197: Direct method call improves code clarity.Using the embedded method directly without going through the Keeper field simplifies the code path.
234-234: Direct method call improves code clarity.Consistent refactoring to use the embedded method directly in GovPublish handler.
275-275: Direct method call improves code clarity.Using the embedded method directly without going through the Keeper field simplifies the code path.
319-319: Direct method call improves code clarity.Same pattern applied consistently to the GovExecuteJSON handler.
358-358: Direct method call improves code clarity.Using the embedded method directly without going through the Keeper field simplifies the code path.
395-395: Direct method call improves code clarity.Same pattern applied consistently to the GovScriptJSON handler.
x/mstaking/keeper/grpc_query.go (8)
42-42: Direct field access improves code clarity.Accessing the ValidatorsByConsPowerIndex field directly from the embedded Keeper struct simplifies the code and aligns with Go's struct embedding best practices.
70-70: Direct field access improves code clarity.Using validatorAddressCodec directly from the embedded Keeper improves readability.
99-99: Direct field access improves code clarity.Accessing DelegationsByValIndex directly from the embedded Keeper struct simplifies the code path.
130-130: Direct field access improves code clarity.Consistent with the pattern applied throughout the file - accessing the embedded field directly.
136-136: Direct field access improves code clarity.Accessing UnbondingDelegationsByValIndex directly from the embedded Keeper struct improves readability.
245-245: Direct field access improves code clarity.Using Delegations directly from the embedded Keeper simplifies the code path.
310-310: Direct field access improves code clarity.Accessing UnbondingDelegations directly from the embedded Keeper struct improves readability.
371-371: Direct field access improves code clarity.Using Delegations directly from the embedded Keeper simplifies the code path.
|
|
||
| // validate the provided status, return all the validators if the status is empty | ||
| if req.Status != "" && !(req.Status == types.Bonded.String() || req.Status == types.Unbonded.String() || req.Status == types.Unbonding.String()) { | ||
| if req.Status != "" && (req.Status != types.Bonded.String() && req.Status != types.Unbonded.String() && req.Status != types.Unbonding.String()) { |
There was a problem hiding this comment.
Fixed logical condition in status validation.
The condition has been changed from using logical OR (||) to logical AND (&&), which fixes a logic error. The previous condition would always evaluate to true for a non-empty status (since a string can't be equal to multiple different values simultaneously). The new condition correctly checks if the status is not equal to any of the valid status values.
Refactor context usage and keeper calls for consistency and clarity. Replaced direct or duplicate contexts, streamlined keeper method calls, and removed unused variables. This improves maintainability and aligns with best practices.